1. Field of the Invention
This invention relates generally to management of bandwidth in a mobile network.
2. Description of Related Art
Wireless devices such as mobile phones and email devices have dramatically changed the way people communicate with one another. With the emergence of compact devices that allow a user to make telephone calls, browse the Internet, watch video, and check email, it is easier than ever for people to exchange information. As the ease of communication for end users has increased, however, the burdens placed on the underlying network infrastructure have also increased. In particular, mobile networks must now provide not only voice services, but also data services.
The designers of mobile networks continuously alter mobile networks for the use of wireless devices as the devices evolve to support large amounts of packet data transfer with different application characteristics. Unfortunately, because the voice network handles both phone calls and packet data transfer using the same architecture and resource-reservation protocols, service providers have been forced to compromise service for some applications. In particular, service providers have added data services onto existing voice networks by selecting a small number of data applications for which a guaranteed Quality of Service (QoS) is provided, while providing only best effort service to the remaining applications.
In current mobile networks, upon receipt of a call request, a radio network controller (RNC) or analogous device performs connection admission control (CAC) that guarantees bandwidth resources in the wireless portion of the network. Accordingly, when a user places a call, the network guarantees the user sufficient bandwidth to complete the call without interruption. This scheme simplifies billing for the service provider, as the service provider can simply charge the user based on the total duration of the call.
Similarly, when the network receives a request for a packet data session, the radio network controller reserves a channel for the data transfer. Problems arise with this approach, as consumers expect to be billed based on the amount of data transferred, rather than the connection time. Accordingly, regardless of the amount of time a customer utilizes a reserved channel, the service provider charges the customer based on the amount of data transferred. This creates an incentive for the service provider to minimize the duration for which a channel is reserved for transfer of packet data.
In order to achieve this goal, service providers use a value known as a “dormancy timer.” Upon reservation of a channel, the device responsible for bandwidth allocation sets a dormancy timer. As the source and destination transfer packet data over the channel, the channel transitions to an active state. Upon completion of the transfer, the channel enters a dormant state and a timer begins. When this timer exceeds the value of the dormancy timer, the channel is closed and the resources are returned to the network for allocation to another user.
As should be apparent from the above description, the use of a dormancy timer attempts to minimize the allocation of resources for packet data sessions. Because the network bears additional costs when establishing a channel, however, a balance must be reached in setting the value of the dormancy timer. In particular, setting the value of the dormancy timer too low will result in frequent reestablishment of channels, thereby inefficiently consuming resources in creating channels and affecting the quality of the user experience. On the other hand, setting the value too high will result in unnecessary reservation of network channels and wasted bandwidth.
Current implementations unsuccessfully attempt to mitigate this problem. One implementation relies on the user endpoint to provide information used by the radio network controller in setting the dormancy timer. This approach has proven to be ineffective, as the user endpoint provides information regarding only the client, not the underlying application. For example, the user endpoint may identify the client as a mobile web browser, but would not identify the particular application, such as sending an email or simple web browsing. This results in significant inefficiencies, as the dormancy requirements for an email transfer and a web browsing session differ dramatically.
Another implementation attempts to address dormancy timer inefficiencies by utilizing a variable dormancy timer policy on a per-user basis. In particular, in one implementation, as a user requests resources for a particular application, a network device identifies applications associated with the flow by examining Layer 3 and Layer 4 packet headers. The network device uses the application information to modify a user-specific profile, including a dormancy timer, based on all flows associated with the user. When allocating bandwidth, the base station controller accesses the user-specific profile and the dormancy timer associated with that particular user.
This implementation fails to effectively implement application-awareness with a satisfactory degree of certainty. More specifically, this implementation assumes that applications comply with the policies set by the Internet Assigned Numbers Authority, which assigns port numbers for each application. This assumption is often erroneous, as applications often “fake” port or header information in order to avoid detection by header-based filters. For example, many peer-to-peer or instant messaging applications attempt to circumvent such filters by modifying TCP or UDP ports to emulate an application that receives preferential treatment in the network.
Accordingly, there is a need for a system and method that enable effective selection of dormancy timer values that overcomes the problems of current implementations. In particular, there is a need for a solution that propagates accurate application information to the entity responsible for bandwidth allocation, such that this entity may appropriately set and modify a dormancy timer based on the underlying application.
The problems described above are illustrative of those that are addressed by the various exemplary embodiments and are not intended to be exhaustive or limiting of the possible problems addressed or solved. Thus, other problems solved by the various exemplary embodiments will be apparent to those of ordinary skill in the art.